Custom Logging (DIY)

Track business transactions from any integration platform—webMethods, IBM Sterling, Apache Camel, MuleSoft, or custom-built solutions—with vendor-neutral logging that integrates seamlessly into Nodinite.

Why Teams Choose Custom Logging

When your integration platform lacks built-in logging or a dedicated Nodinite agent, Custom Logging bridges the gap—transforming integration chaos into unified visibility:

• Unify 8+ platforms - Eliminate log silos across webMethods, IBM Sterling, Apache Camel, MuleSoft, and custom solutions with consistent search and correlation
• Reduce troubleshooting time 75% - Implement ApplicationInterchangeId correlation across platforms—troubleshoot end-to-end in minutes instead of hours
• Enable self-service analytics - Extract Order Numbers, Customer IDs, and amounts into searchable fields—business users answer their own questions without SQL
• Accelerate compliance audits 95% - Centralize immutable audit trails with instant exports—SOX/GDPR/HIPAA audit prep from 3 weeks to 90 seconds
• Detect silent failures - Non-Events Monitoring alerts when expected messages don't arrive—catch production issues before customer impact
• Escape vendor lock-in - Appender-based abstraction (Log4Net, Serilog, Log4J) lets you swap platforms without rewriting logging code

Nodinite Custom Logging transforms fragmented platform-specific logs into unified business intelligence:

✅ Log from any platform—webMethods, IBM Sterling, Apache Camel, MuleSoft, Frends, iCore, TEIS, custom .NET/Java/Node.js solutions
✅ Vendor-neutral architecture—appender-based (Log4Net, Serilog, Log4J) prevents lock-in, supports multiple destinations
✅ Asynchronous reliability—Pickup Service fetches logs from queues/files/databases without blocking your integrations
✅ Business-data extraction—Message Types + Search Field Expressions extract Order Numbers, Customer IDs, Transaction codes for self-service search
✅ End-to-end correlation—Track transactions across 8+ systems using ApplicationInterchangeId with BPM visualization
✅ Proven templates ready—Mule ESB connector, .NET samples, Serilog appenders, WCF diagnostics—start in hours, not weeks
✅ Zero integration changes—Add logging without modifying existing platform logic or deployment processes

Important

Always set OriginalMessageTypeName for searchable business data - When implementing Custom Logging, the Message Types field is critical for enabling business intelligence features. Without proper Message Types:

1. Search Field Expressions cannot extract Order Numbers, Customer IDs, Invoice amounts, Transaction codes, or other business identifiers
2. Log Views can only search by timestamps and correlation IDs, not by business data
3. Non-Events Monitoring cannot track message volumes, detect missing messages, or alert on pattern anomalies
4. Business Process Modeling (BPM) cannot correlate transactions end-to-end across your custom solution and other systems

Set OriginalMessageTypeName in your JSON Log Event before writing to intermediate storage. Plan your Message Types during development—they define how Nodinite extracts searchable business data from your logged messages. Message Types cannot be changed after events are logged.

Diagram: Custom Logging architecture—shows how reusable logging logic in your integration solution produces Nodinite JSON Log Events, which the Pickup Service asynchronously collects and delivers to the Nodinite Log API.

Customers and Partners have successfully used Custom Logging to log business transactions to Nodinite from:

• Apache Camel
• IBM Sterling
• iCore
• Frends
• Ghostnodes
• MoveIT
• TEIS (TietoEvry)
• webMethods (Software AG)

Design Goals

When your integration platform lacks built-in tracking or a Nodinite Logging Agent, you must produce a JSON formatted Log Event and place it on a highly available target (such as a queue, file share, or database).

The Nodinite Pickup Log Events Service Logging Agent fetches your Log Events asynchronously, so you write less custom code, achieve reliable logging, and prevent overloading Nodinite in your custom-built solutions.

Diagram: Two approaches—Async (recommended) and Synchronous logging. Async uses intermediate storage and Pickup Service for reliability and scalability.

1. Async Log Event – Asynchronous Logging
2. Synchronous Log Event (NOT recommended)

Custom Logging Checklist

Follow these best practices for your Custom Logging strategy:

• Configure Message Types FIRST - Plan your Message Types before writing logging code. This is mandatory for searchable business data.
• Define Search Field Expressions - Configure which business identifiers to extract (Order Numbers, Customer IDs, Invoice amounts, etc.) based on your Message Types.
• Make Custom Logging Asynchronous for reliability and scalability.
• Use an appender-based strategy to avoid vendor lock-in.
  • Log4Net Appender
  • Serilog
  • WCF
  • Log4J
• Provide all necessary data:
  • OriginalMessageTypeName (mandatory for business intelligence)
  • Properties (key/value) via Context Options
  • Message Body/Bodies (XML, JSON, Flatfile, CSV, EDIFACT, X12, ...)
  • Correlation IDs (ApplicationInterchangeId) for transaction tracking
• Write custom code with a vendor-neutral abstraction layer to prevent lock-in.
• Reuse a shared custom Logging component to support multiple, replaceable destinations.
• Create role-based Log Views - Enable business users to self-service search by business data.
• Configure Non-Events Monitoring - Track expected message volumes and alert on anomalies.
• Design BPM processes - Correlate end-to-end transactions across systems using Message Types.

Choose Your Logging Approach

Pick the approach that fits your platform and team. All three produce the same JSON Log Events.

Whichever approach you choose, write to intermediate storage (a queue, folder, or database) and let the Pickup Service deliver to the Log API, so logging never blocks your integrations. This Asynchronous Logging is recommended over calling the Log API directly.

Real-World Impact

See proven results from customer implementations:

Get Started

Note

Log basic events first (timestamps, status codes, correlation IDs), add Message Types and Search Fields in week 2 for business-data extraction, add Non-Events Monitoring and BPM in weeks 3-4 for advanced features.

View detailed implementation steps → • Browse FAQ answers →

What firewall settings are required?

Your solution never connects to Nodinite directly, so you open these hops only:

• Your solution → intermediate storage: the storage's own port, for example SMB 445 for a file share, 1433 for SQL Server, 5671-5672 and 443 for Azure Event Hubs or Service Bus, or 443 for Azure Blob Storage. A local folder or database needs no rule.
• Pickup Service → intermediate storage: the same port, outbound from the server that runs the Pickup Service.
• Pickup Service → Log API: the Log API site port, set per environment in the Nodinite Portal. No rule is needed when both run on the Core Services Server.

The Pickup Service firewall settings list every port and hostname per storage type.

Next Steps

Ready to implement Custom Logging? Start with Message Types (mandatory), then review the .NET Hello World Sample or Mule ESB Custom Connector for your platform. Install Pickup Service and create role-based Log Views for business users.

Related Topics

• Log API Overview
• JSON Log Events
• Pickup Service
• Message Types
• Search Field Expressions
• Log Views
• Non-Events Monitoring
• Business Process Modeling